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ABSTRACT:  Software  is  ubiquitous.  Many  of  the  products,  services,  and  pro¬ 
cesses  organizations  use  and  offer  are  highly  dependent  on  software  to  handle 
the  sensitive  and  high-value  data  on  which  people’s  privacy,  livelihoods,  and 
very  lives  depend.  National  security — and  by  extension  citizens’  personal  safe¬ 
ty — relies  on  increasingly  complex,  interconnected,  software-intensive  infor¬ 
mation  systems — systems  that  in  many  cases  use  the  Internet  or  Internet-exposed 
private  networks  as  their  means  for  communication  and  transporting  data. 
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INTRODUCTION 

Dependence  on  information  technology  makes  software  security  a  key  element 
of  business  continuity,  disaster  recovery,  incident  response,  and  national  securi¬ 
ty.  Software  vulnerabilities  can  jeopardize  intellectual  property,  consumer  trust, 
business  operations  and  services,  and  a  broad  spectrum  of  critical  applications 
and  infrastructures,  including  everything  from  process  control  systems  to  com¬ 
mercial  application  products. 

The  integrity  of  critical  digital  assets  (systems,  networks,  applications,  and  in¬ 
formation)  depends  on  the  reliability  and  security  of  the  software  that  enables 
and  controls  those  assets.  However,  business  leaders  and  informed  consumers 
have  growing  concerns  about  the  scarcity  of  practitioners  with  requisite  compe¬ 
tencies  to  address  software  security  [Carey  2006].  They  have  concerns  about 
suppliers’  capabilities  to  build  and  deliver  secure  software  that  they  can  use  with 
confidence  and  without  fear  of  compromise.  Application  software  is  the  primary 
gateway  to  sensitive  information.  According  to  the  Deloittesurvey  of  169  major 
global  financial  institutions,  2007  Global  Security  Survey:  The  Shifting  Security 
Paradigm  [Deloitte  2007],  current  application  software  countermeasures  are  no 
longer  adequate.  In  the  survey,  Gartner  identifies  application  security  as  the 
number  one  issue  for  chief  information  officers  (CIOs). 

The  absence  of  security  discipline  in  today’s  software  development  practices 
often  produces  software  with  exploitable  weaknesses.  Security-enhanced  pro¬ 
cesses  and  practices — and  the  skilled  people  to  manage  them  and  perform 
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Public  reporting  burden  for  the  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources,  gathering  and 
maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  collection  of  information, 
including  suggestions  for  reducing  this  burden,  to  Washington  Headquarters  Services,  Directorate  for  Information  Operations  and  Reports,  1215  Jefferson  Davis  Highway,  Suite  1204,  Arlington 
VA  22202-4302  Respondents  should  be  aware  that  notwithstanding  any  other  provision  of  law,  no  person  shall  be  subject  to  a  penalty  for  failing  to  comply  with  a  collection  of  information  if  it 
does  not  display  a  currently  valid  OMB  control  number 
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them — are  required  to  build  software  that  can  be  trusted  to  operate  more  securely 
than  software  being  used  today. 

That  said,  there  is  an  economic  counter-argument,  or  at  least  the  perception  of 
one.  Some  business  leaders  and  project  managers  believe  that  developing  secure 
software  slows  the  process  and  adds  to  the  cost  while  not  offering  any  apparent 
advantage.  In  many  cases,  when  the  decision  reduces  to  “ship  now”  or  “be  secure 
and  ship  later,”  “ship  now”  is  almost  always  the  choice  made  by  those  who  con¬ 
trol  the  money  but  have  no  idea  of  the  risks.  Information  to  combat  this  argu¬ 
ment,  including  how  software  security  can  potentially  reduce  cost  and  schedule, 
is  becoming  available  based  on  earlier  work  in  software  quality  and  the  benefits 
of  detecting  software  defects  early  in  the  life  cycle  along  with  documented  expe¬ 
riences  such  as  Microsoft’s  Security  Development  Lifecycle. 


THE  GOAL  OF  SOFTWARE  SECURITY  ENGINEERING 

Software  security  engineering  is  using  practices,  processes,  tools,  and  techniques 
that  enable  you  to  address  security  issues  in  every  phase  of  the  software  devel¬ 
opment  life  cycle  (SDLC).  Software  that  is  developed  with  security  in  mind  is 
typically  more  resistant  to  both  intentional  attack  and  unintentional  failures.  One 
view  of  secure  software  is  software  that  is  engineered  “so  that  it  continues  to 
function  correctly  under  malicious  attack”  [McGraw  2006]  and  is  able  to  recog¬ 
nize,  resist,  tolerate,  and  recover  from  events  that  intentionally  threaten  its  de¬ 
pendability.  Broader  views  that  can  overlap  with  software  security  (for  example, 
software  safety,  reliability,  and  fault  tolerance)  include  proper  functioning  in  the 
face  of  unintentional  failures  or  accidents  and  inadvertent  misuse  and  abuse,  as 
well  as  reducing  software  defects  and  weaknesses  to  the  greatest  extent  possible 
regardless  of  their  cause. 

The  goal  of  software  security  engineering  is  to  build  better,  defect-free  software. 
Software-intensive  systems  that  are  constructed  using  more  securely  developed 
software  are  better  able  to 

•  continue  operating  correctly  in  the  presence  of  most  attacks  by  either  resist¬ 
ing  the  exploitation  of  weaknesses  in  the  software  by  attackers  or  tolerating 
the  failures  that  result  from  such  exploits 

•  limit  the  damage  resulting  from  any  failures  caused  by  attack-triggered 
faults  that  the  software  was  unable  to  resist  or  tolerate  and  recover  as  quickly 
as  possible  from  those  failures 
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SOFTWARE  SECURITY  PRACTICES 

No  single  practice  offers  a  universal  silver  bullet  for  software  security.  With  this 
in  mind.  Software  Security  Engineering:  A  Guide  for  Project  Managers  provides 
software  project  managers  with  sound  practices  that  they  can  evaluate  and  selec¬ 
tively  adopt  to  help  reshape  their  own  development  practices.  The  objective  is  to 
increase  the  security  and  dependability  of  the  software  produced  by  these  prac¬ 
tices,  both  during  its  development  and  its  operation. 

The  book  (and  material  referenced  on  the  Build  Security  In  Web  site  described 
below)  identifies  and  compares  potential  new  practices  that  can  be  adapted  to 
augment  a  project’s  current  software  development  practices,  greatly  increasing 
the  likelihood  of  producing  more  secure  software  and  meeting  specified  security 
requirements.  As  one  example,  assurance  cases  can  be  used  to  assert  and  specify 
desired  security  properties,  including  the  extent  to  which  security  practices  have 
been  successful  in  satisfying  security  requirements. 

Software  developed  and  assembled  using  software  security  practices  should  con¬ 
tain  significantly  fewer  exploitable  weaknesses.  Such  software  can  then  be  relied 
on  to  more  capably  recognize,  resist  or  tolerate,  and  recover  from  attacks  and 
thus  function  more  securely  in  an  operational  enviromnent.  Project  managers 
responsible  for  ensuring  that  software  and  systems  adequately  address  their  secu¬ 
rity  requirements  throughout  the  SDLC  can  review,  select,  and  tailor  guidance 
from  the  book,  the  Build  Security  In  Web  site,  and  the  sources  cited  throughout 
the  book  as  part  of  normal  project  management  activities. 

The  five  key  take-aways  of  Software  Security  Engineering  are  as  follows: 

1 .  Software  security  is  about  more  than  eliminating  vulnerabilities  and  con¬ 
ducting  penetration  tests.  Project  managers  need  to  take  a  systematic  ap¬ 
proach  to  incorporate  the  sound  software  security  practices  into  their  devel¬ 
opment  processes.  Examples  include  security  requirements  elicitation, 
attack  pattern  and  misuse/abuse  case  definition,  architectural  risk  analysis, 
secure  coding  and  code  analysis,  and  risk-based  security  testing. 

2.  Network  security  mechanisms  and  IT  infrastructure  security  services  do  not 
sufficiently  protect  application  software  from  security  risks. 

3.  Software  security  initiatives  should  follow  a  risk  management  approach  to 
identify  priorities  and  what  is  good  enough,  understanding  that  software  se¬ 
curity  risks  will  change  throughout  the  development  lifecycle.  Risk  man¬ 
agement  reviews  and  actions  are  conducted  during  each  phase  of  the  SDLC. 

4.  Developing  secure  software  depends  on  understanding  the  operational  con¬ 
text  in  which  it  will  be  used.  This  context  includes  conducting  end-to-end 
analysis  of  cross-system  work  processes,  working  to  contain  and  recover 
from  failures  using  lessons  learned  from  business  continuity,  and  exploring 
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failure  analysis  and  mitigation  to  deal  with  system  and  system  of  system 
complexity. 

5.  Project  managers  and  software  engineers  need  to  learn  to  think  like  an  at¬ 
tacker  in  order  to  address  the  range  of  things  that  software  should  not  do 
and  how  software  can  better  resist,  tolerate,  and  recover  when  under  attack. 
The  use  of  attack  patterns  and  misuse/abuse  cases  throughout  the  SDLC  en¬ 
courages  this  perspective. 


Practice  Maturity  and  Relevance 

As  a  community,  we  recognize  that  some  software  security  practices  are  in 
broader  use,  and  thus  more  tested  and  mature,  than  others,  such  as  security  cod¬ 
ing  practices  and  testing  for  vulnerabilities.  As  a  practice  description  and  selec¬ 
tion  aid,  descriptive  tags  mark  the  book’s  sections  and  key  practices  in  two  prac¬ 
tical  ways: 

•  Identifying  the  content’s  relative  “maturity  of  practice”  as  follows: 

LI :  The  content  provides  guidance  for  how  to  think  about  a  topic 
for  which  there  is  no  proven  or  widely  accepted  approach.  The  in¬ 
tent  of  the  description  is  to  raise  awareness  and  aid  in  thinking 
about  the  problem  and  candidate  solutions.  The  content  may  also 
describe  promising  research  results  that  may  have  been  demon¬ 
strated  in  a  constrained  setting. 

L2:  The  content  describes  practices  that  are  in  early  pilot  use  and 
are  demonstrating  some  successful  results. 

L3 :  The  content  describes  practices  that  are  in  limited  use  in  in¬ 
dustry  or  government  organizations,  perhaps  for  a  particular  mar¬ 
ket  sector. 

L4:  The  content  describes  practices  that  have  been  successfully 
deployed  and  are  in  widespread  use.  These  practices  can  be  used 
with  confidence.  Experience  reports  and  case  studies  are  typically 
available. 

•  Identifying  the  designated  audiences  for  which  each  chapter  section  or  prac¬ 
tice  is  most  relevant: 

E:  executive  and  senior  managers 
M:  project  and  mid-level  managers 

L:  technical  leaders,  engineering  managers,  first  line  managers, 
and  supervisors 


3  |  SOFTWARE  SECURITY  ENGINEERING:  A  GUIDE  FOR  PROJECT  MANAGERS 


BUILD  SECURITY  IN:  A  KEY  RESOURCE 

Since  2004,  the  U.S.  Department  of  Homeland  Security  Software  Assurance 
Program  has  sponsored  development  for  the  Build  Security  In  (BSI)  Web  site, 
which  is  one  of  the  significant  resources  used  in  developing  Software  Security 
Engineering.  BSI  content  is  based  on  the  principle  that  software  security  is  fun¬ 
damentally  a  software  engineering  problem  and  must  be  managed  in  a  systematic 
way  throughout  the  SDLC. 

BSI  contains  and  links  to  a  broad  range  of  information  about  sound  practices, 
tools,  guidelines,  rules,  principles,  and  other  knowledge  to  help  project  managers 
deploy  software  security  practices  and  build  secure  and  reliable  software.  Con¬ 
tributing  authors  to  this  book  and  the  articles  appearing  on  the  BSI  site  include 
senior  staff  from  the  Carnegie  Mellon  Software  Engineering  Institute  (SEI)  and 
Cigital,  Inc.,  as  well  as  other  experienced  software  and  security  professionals. 

BSI  content  is  referenced  throughout  the  book.  Readers  can  consult  BSI  for  addi¬ 
tional  details,  ongoing  research  results,  and  information  about  related  Web  sites, 
books,  and  articles. 

Start  the  Journey 

As  software  and  security  professionals,  we  will  never  be  able  to  get  ahead  of  the 
game  by  addressing  security  solely  as  an  operational  issue.  Attackers  are  crea¬ 
tive,  ingenious,  and  increasingly  motivated  by  financial  gain.  They  have  been 
learning  how  to  exploit  software  for  several  decades;  the  same  is  not  true  for 
software  engineers,  and  we  need  to  change  this.  Given  the  extent  to  which  our 
nations,  our  economies,  our  businesses,  and  our  families  rely  on  software  to  sus¬ 
tain  and  improve  our  quality  of  life,  we  must  make  significant  progress  in  putting 
higher  quality  and  more  secure  software  into  production.  The  practices  described 
in  Software  Security  Engineering  serve  as  a  useful  starting  point. 

Each  project  manager  needs  to  carefully  consider  the  knowledge,  skills,  and 
competencies  of  their  development  team,  their  organizational  culture’s  tolerance 
(and  attention  span)  for  change,  and  the  degree  to  which  sponsoring  executives 
have  bought  in  (a  prerequisite  for  sustaining  any  improvement  initiative).  In 
some  cases,  it  may  be  best  to  start  with  secure  software  coding  and  testing  prac¬ 
tices  given  that  these  are  the  most  mature,  have  a  fair  level  of  automated  support, 
and  can  demonstrate  some  early  successes,  providing  visible  benefit  to  help 
software  security  efforts  gain  support  and  build  momentum.  On  the  other  hand, 
secure  software  requirements  engineering  and  architecture  and  design  practices 
offer  opportunities  to  address  more  substantive  root  cause  issues  early  in  the  life 
cycle  that  if  left  unaddressed  will  show  up  in  code  and  test.  Practice  selection 
and  tailoring  are  specific  to  each  organization  and  project  based  on  objectives, 
constraints,  and  the  criticality  of  the  software  under  development. 
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Project  managers  and  software  engineers  need  to  better  understand  what  consti¬ 
tutes  secure  software  and  develop  their  skills  to  think  like  an  attacker  so  this 
mindset  can  be  applied  throughout  the  SDLC.  The  book  describes  practices  to 
get  this  ball  rolling,  such  as  attack  patterns  and  assurance  cases.  Alternatively,  if 
you  have  access  to  experienced  security  analysts,  adding  a  few  of  them  to  your 
development  team  can  get  this  jump  started. 

Two  of  the  key  project  management  practices  are  (1)  defining  and  deploying  a 
risk  management  framework  to  help  inform  practice  selection  and  determine 
where  best  to  devote  scarce  resources  and  (2)  identifying  how  best  to  integrate 
software  security  practices  into  the  organization’s  current  software  development 
life  cycle. 

John  Steven  states  [Steven  2006] 

“Don  7  demand  teams  to  begin  conducting  every  activity  on  day  one. 

Slowly  introduce  the  simplest  activities  first,  then  iterate. 

“[Have]  patience.  It  will  take  at  least  three  to  five  years  to  create  a 
working,  evolving  software  security  machine.  Initial  organization-wide 
successes  can  be  shown  within  a  year.  Use  that  time  to  obtain  more 
buy-in  and  a  bigger  budget.  ” 

Clearly  there  is  no  one-size-fits-all  approach.  Project  managers  and  their  teams 
need  to  think  through  the  choices,  define  their  tradeoff  and  decision  criteria, 
learn  as  they  go,  and  understand  that  this  effort  requires  continuous  refinement 
and  improvement. 


IN  CLOSING 

Sound  software  security  engineering  practices  should  be  incorporated  throughout 
the  entire  software  development  life  cycle.  Software  Security  Engineering  is  one 
resource  that  captures  both  standard  and  emerging  software  security  practices 
and  explains  why  they  are  needed  to  develop  more  security-responsive  and  ro¬ 
bust  systems. 
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